Hello, as you could expect this Friday facts is mainly about our fight with the avalanche of bug reports, which is actually not as huge as we expected it to be to be honest. We released 0.16.7 yesterday, and this will probably be the last update for a while. Most of us now are taking a break, enjoying the festivities, and visiting our friends and family.
Game Developers Session 2018 GDS 2018 will be taking place next week, running from Friday 7th to Saturday 8th. This year, like last year, we are silver sponsors of the event, which means you will see some Factorio branding around the event and in their official booklet. Part of the preparation on our side was to produce a nice graphical asset for their use, which you can see below: The image is an aesthetic composition to showcase the design and theme of the game and its elements (while not necessarily making logical sense), and also contains the first public display of our new official Wube Software logo. About half the office team here will be attending the event, so if you are also going you might bump into us.
Hello inhabitants of a remote and unexplored planet full of life, richness and natural resources. The group of entities we are bringing to high resolution currently is the combinators. The main problem with them is the amount of shifting values needed, so we used a specific workflow which I will try to show and explain today. Some of the parts have already been described in FFF 146, so I will only mention what is necessary for this article. Please fasten your belt as this will be a ride full of automation.
Good day to all, it is hot here. Really hot. We have loosened our "dressing policy" to "no T-shirt is fine". Both of our fans are running full speed and the fridge is stacked with ice cube plates. People come and go all the time - it is the mids of vacation period after all. Half empty (or half full) office has become a standard these days. Still the work goes on and there is progress.
Mod settings Right now when you want to customize a particular mod you have to: Know what folder the mods are stored on your computer Unzip the mod Figure out what line of which file has the thing you want to change Save and optionally re-zip the mod Hope what you changed is compatible with the way the rest of the mod works The game also forces everyone playing on the same multiplayer session to have identical mod files so any changes you've made make it impossible for you to join others unless they also have made those changes. This also makes it difficult for mod developers to troubleshoot bug reports because they don't know what you might have changed. This is obviously not so great and I want to address the main problem: there's no good way for mod developers to give users any portable way to configure their mods. To fix this we're going to add the ability for mods to define settings that will be presented like our in-game options menu now under a new section "options -> mods". This will let mods give some basic information about what kind of setting they have and we can present it to the player in a (hopefully) nice GUI with verification and feedback about why what they've entered isn't valid (if it's not valid) as well as the ability to change them runtime should the particular setting allow it. We can then sync these settings on joining multiplayer sessions (or not should you not want your settings to carry between games) and everything will just work.
Hello fellow builders, There is this commotion about the paid mods on Steam. (It had been cancelled already). I understand that the implementation was far from optimal, as people would be suddenly expected to pay for mods that were free until now. It was also sad, that the modders were to get only 25% percent of the money. But I personally think, that there is nothing wrong about the idea generally. If a reasonable price tag on a great mod allows the creator to develop the mod full time, create professional content, and people are willing to pay for it, everyone wins. Free mods would still exist so it would be up to the players to choose. I'm NOT saying we are going to allow paid mods for Factorio anytime soon. But I'm not denying this possibility in the far future.
Good evening everyone, it is almost 1 year since the end of our Indiegogo campaign. The beginning of the campaing was kind of gloomy and hopeless, after one week we were ready to resign the whole project and we both even had a programming job in reserve. But eventually things turned around and thanks to many awesome people supporting us, we managed to finish the campaign sucessfully and continue working on Factorio fulltime. That is the "well known history" and you can read more about it in the older blog posts. What is less known is what happened after the campaign. The end of the campaign made us actually over confident at the time. We felt that all is going to be easy peasy since then. We were wrong once again. We had to go through some rough times, often balancing close to the zero on our bank account with the game being not more than "an interesting proof of concept". The original estimate was that the game would be finished by the summer of 2013, simply because the summer seemed like far enough in the future back then in February. Now we believe that if we try hard enough, the game could be "finished" by summer 2015 (because that DOES look like far enough in the future :)), but better not to make any estimates ... So these days it is a bit of balancing time for us, comparing to where we were a year ago. The "now" is definitely winning (except for the compilation times). The efforts to stabilize the 0.9 release have continued this week as well. We want the 0.9.2 to be a "stable release candidate", that means it should have all the major reported bugs fixed and the campaings and scenario pack must be working. This is not ready at the moment, therefore we will wait with the 0.9.2 release till sometimes in the next week. Also recently we have spent quite some time on administrative tasks - namely working out the taxes and also going through the application process for accepting credit cards on our website (let's keep the fingers crossed that paymill will give us a green light in the end). Albert has been busy (as usual) and productive (as usual as well). We decided to spend some time repairing our graphical debts and redo the most common entities that were done before our artistic direction has been established. First in the row was the assembling machine. You can say goodbye to "tint abuse" that was used to produce two extra levels from a single assembling machine animation. Now there are three separate animations with different movement mechanisms in the top part. The preview of animations is shown below. The problem is that the less "old style" (and non-fitting) objects there are in the game, the more visible they are compared to the rest. This makes the inserters and transport belts next candidates for re-skinning ... If you like the new assembling machines (and even if you don't), then tell us about it on our forum.
Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
Hello, version 0.15.30 was released today, and we consider it to be our first 0.15 stable version candidate, as long as no other big bugs appear, we will have 0.15 stable in a week. As the teasing never ends, it is time to show some ongoing work on 0.16 already.
